小公司的需求评审，竟然是这样？

大家好，我是程序员鱼皮。今天分享一个有趣的内容，给大家看看我们鱼厂的需求评审是怎么做的，怎么给开发同学安排需求。

虽然我们是小团队，但是和大厂相比，除了参会人数少了些、少了点开发和产品之间的拉扯外，整个需求评审的流程非常标准。

整个需求评审会都是真实录制。这次做的是一个公司内部自用的公众号管理系统，参会者是我、还有一位后端开发实习生，视频中会稍微有一些 “指引新人” 的成分。

大家看完这个视频后，能快速学习到：

• 评审需求的流程和方法
• 如何帮助我们明确需求
• 如何进行需求调研等等

希望能帮助开发同学提高需求完成的效率，拒绝不明确的需求、拒绝无意义的需求！尤其对没进过公司的同学会更有帮助~

视频

视频如下：

B 站地址：https://www.bilibili.com/video/BV1Gw4114795

再用文字总结一些关键内容，照顾下爱阅读的小伙伴。

文字总结

这次我们要做的是一个公众号管理系统，包括多公众号的增删改查、菜单设置、自动回复设置等，目的是提高运营公众号平台的效率。

由于这个需求非常典型，在自己开发之前，首先要做的是 充分的调研，看看有没有现成的、开源的系统，这样就不用自己开发了。最好输出一篇详细的调研文档，而不是口说无凭。

经过实习生的调研发现，市面上现存的公众号管理系统要么无法满足我们的诉求、要么就是功能过于复杂（我们用不上），所以决定自己开发。

但是在自己开发前，如果之前完全没做过类似的系统，那么一定要做 技术调研，看看有没有 API、或者现成的 “轮子” 能实现这个需求。技术调研做的好，能给你之后的开发省去大把的时间，也能让你的排期更准确。比如使用 WxJava 开源库，几行代码就能轻松操作公众号，而如果你不知道这个库，消耗的时间可能会多个好几倍，而且还会有一堆 Bug。

做了充分的调研后，我们就更明确要做的需求以及如何实现需求，接下来要做的就是拆分需求为各个小功能点，然后按照功能的重要性、实现难易度等方式编排优先级。原则上先做最核心的功能，比如添加公众号功能，如果这一步不做，其他的功能都做不了。而且刚开始做需求时不要想着一步到位，应该先把最基础的功能完成、程序能跑就行，然后再去优化迭代、逐步完善功能。否则前期你做的越多，后面要改的内容也越多。

最后一步，就是根据上面的讨论结果和信息，去定一个需求的截止时间。除非紧急需求，否则一般截止时间是需要多方共同商讨的。像我自己做过公众号管理系统，就很清楚它的实际开发成本，用现成的库基本上写不了多少后端代码；参会的实习生呢经过充分的调研，也清楚这个需求应该怎么实现了。所以我们最终定的是一周内完成。

最后的结果是，最终这位实习生在没加班的情况下，超前完成了工作。这就是需求评审会、以及调研排期等操作的价值。

对了，再补充一点，整个会议最好产出一个文档来记录关键内容，否则嘛。。如下图：

---

我相信很多实际工作过的程序员都经历过大大小小的需求评审，有的可能是像我们一样流程很标准，有的可能就是产品经理（老板）跟你说一句话，就让你做一个需求。如果工期说的长了，你就偷着乐吧；如果工期说短了，导致你天天加班，到时候骂的要多难听有多难听。

所以下次给需求排期的时候，要有理有据，如果调研后发现需求真的没啥价值，那么就大胆地说：“这个需求做不了！这个需求我不做！”

👇🏻 点击下方阅读原文，获取鱼皮往期编程干货。

往期推荐